IBIS Macromodel Task Group Meeting date: 25 July 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: * Dian Yang Cadence Design Systems: * Ambrish Varma * Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Liwei Zhao Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Kinger: Send out draft13 of the PSIJ Sensitivity proposal including more feedback from Fangyi and the ATM meeting. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 11th meeting. Kinger moved to approve the minutes. Michael seconded the motion. There were no objections. -------------- New Discussion: PSIJ Sensitivity Discussion: Kinger had emailed draft13 to the ATM list. Draft13 contained the changes discussed at the previous meeting, including moving large sections of the introductory text from the "Proposed Changes" section to the "Definition of the Issue" section. Kinger reviewed an in-progress draft14 including additional feedback from Fangyi. Fangyi had asked whether we should make the entries in [PSIJ Sensitivity Signal] complex and include the phase information to account for delay. Kinger agreed with this suggestion, and he had added a new phase column to the keyword. In the Example section, all the entries in the phase column are 0. Kinger said model makers may choose to keep it simple and use 0 degree phase entries to start and then add phase information in later revisions of a model. Arpad suggested that the "amplitude" column should be renamed "magnitude". Bob suggested that we explicitly limit the phase column values to 0 to 360 degrees. Kinger agreed with both suggestions. Kinger also noted figure 5, which illustrates two possible Jitter Transfer Functions (JTF)s. He said JTFs can be very different: low-pass, high-pass, band-pass, for example. Kinger said he would send out draft14. [AMI Test Load] and [AMI Test Data]: Michael reviewed draft2 of the proposal, which he had previously emailed to the ATM list. Per the discussions in ATM when he previously presented draft1: - There are now only 2 keywords, [AMI Test Data] and its hierarchically scoped keyword [Waveform]. - The [AMI Test Load] keyword has been removed, and this proposal now focuses strictly on testing the algorithmic portions of the AMI model. Test channel information is deferred. Any possible updates to the existing [Test Load] and [Test Data] keywords to make them useful for AMI would be handled in a separate BIRD. - [AMI Test Data] defines the Model, Corner, and Direction of the test case. - [Waveform] contains: - Type (Statistical or Time_domain) - Direction - Paths to files containing everything else: - AMI_parameters_file - This file contains the information a tool would pass into the model to fully define the simulation and includes, AMI parameter values, sample_interval, symbol_time, etc. - Stimulus_file - This file contains the stimulus waveform passed into the model. - Waveform_file - This file contains a waveform representing the expected output of the AMI model. - Clock_file (new to this version) - This file contains the expected clock_times output of the AMI model. Michael noted that the new version supports crosstalk and supports verification of the model's output clock_times. Ambrish asked, as he had in previous meetings, why we wouldn't just use the existing parameters string format directly, rather than specifying a list of values of the AMI parameters. Michael said he had no objection to this, but it would not solve the other issues related to specifying waveforms and other values such as symbol_time. Arpad asked about how we might deal with large file sizes for stimulus and waveform files. He said that if we have long waveforms (e.g., 1e-6 seconds) and short sample intervals (e.g., 1e-12 seconds) then we might need long waveforms and high precision numbers to represent the time values. These could combine to give us huge text file sizes. Michael observed that legacy IBIS keywords do not attempt to define the precision of the values, but Arpad noted the legacy keywords are typically limited to 1000 values. Fangyi then noted that we can save half the file size because AMI is fixed timestep. So, we don't need to specify each t value. We need only worry about the V values in most cases. The only time we would need to provide time values is for a stimulus to a model with Rx_Use_Clock_Input set to the value "Times". Ambrish asked how the model maker/tool/user would know whether the data was before or after Ignore_Bits. Michael said the proposal envisions everything starting from t=0, so the data covering the Ignore_Bits time would have to be included. Fangyi asked whether we should also compare the AMI_parameters_out string returned by the model. Michael said he had considered this, and we could add the output string information to the [Waveform] keyword. Fangyi said this brings up the question of the block size of the data in the AMI_GetWave call, as you would have to control this to ensure you knew what to expect in AMI_parameters_out. Arpad agreed and mentioned his recent discussion topic based on the possible interaction between the block size and the time constant of any AMI models that continuously adapt. Michael agreed, but he noted that the wave_size (i.e., block size) is already specified in his proposal as part of the AMI_parameters_file. Michael returned to Fangyi's suggestion about eliminating the time values. He said that he currently includes two columns for the waveforms, but we can reduce that to one column. He said the question was whether we start from t=0. Arpad asked whether we could save space by specifying a non-zero value for the start of the waveform data if the model maker chose to do so. He agreed that the stimulus waveform would have to start from t=0 all the time. Ambrish said that allowing a non-zero start value for the waveform complicates things. For one thing, we then lose the assumption that the stimulus and waveform are the same size. It also potentially eliminates the quick correlation you can immediately get if you start at t=0. Michael agreed that it would be Ignore_Bits by another name. Fangyi asked what the benefit of allowing the waveform to start at a non- zero t would be. He said it's a lot of work and complication to save a little file space. Michael summarized his takeaways and possible changes for the proposal: - Investigate use of the existing Table Format for the AMI parameters and the waveforms themselves - Include AMI_parameters_out as a quantity that can be compared - Michael: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. New ARs: Kinger: Send out draft14 of the PSIJ Sensitivity proposal including more feedback from Fangyi and the ATM meeting. ------------- Next meeting: 01 August 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives